1. Field of Invention
The present invention relates generally to internet protocol (IP) signaling in networks. More particularly, the present invention relates to extending a resource reservation protocol for use in enabling on-path admission control at Ethernet switching hops located between IP hops.
2. Description of the Related Art
An on-path Internet Protocol (IP) reservation protocol is a reservation protocol in which reservation messages and reservation state are established and maintained along the path between an IP sender and IP receiver. One example of an on-path IP reservation protocol, or an on-path signaling protocol, is a resource reservation protocol (RSVP). RSVP is used in networks that enable Internet applications to obtain quality of service for their traffic. RSVP, while not a routing protocol, works in conjunction with routing protocols such as unicast and multicast routing protocols. RSVP effectively carries a request through elements of a network, and attempts to make a resource reservation at each appropriate element in order to achieve a particular quality of service end to end.
To attempt to make a resource reservation at a network element, e.g., at a router or a server, in response to a resource reservation request, an RSVP daemon of the network element may communicate with an admission control module of the network element. The admission control module generally ascertains whether the network element is able to accommodate the resource reservation request, i.e., whether the network element is able to provide the requested quality of service. If the network element does not have sufficient resources to provide the requested quality of service, an error notification is sent to the application that initiated the resource reservation request. Otherwise, a resource reservation is made at the network element.
Typically, a resource reservation request begins with a path (PATH) message being sent from a sender or a source to a receiver or a destination. After receiving the PATH message, the receiver sends a reservation (RESV) message back to the sender. The network elements traversed by the PATH message and the RESV message may include IP capable network elements, e.g., layer 3 elements with respect to the Open Systems Interconnection (OSI) reference model specification which may thus be RSVP capable, and network elements that are not IP capable, e.g., layer 2 elements with respect to the OSI reference model specification such as Ethernet switches, which therefore are not RSVP capable. It should be appreciated that some layer 3 elements are also not RSVP capable.
FIG. 1 is a block diagram representation of a network with IP-capable network elements and a non IP-capable Ethernet switch, in which a resource reservation is to be made. In a network 100, a sender 104 that has a sender or source IP address of IP_0 sends a PATH message 122 towards a receiver 118. PATH message 122 includes the sender IP address of IP_0 and a receiver IP address of IP_3. Before PATH message 122 reaches receiver 118, PATH message 122 passes through RSVP capable routers 106, 114 and an Ethernet switch 110, which is not IP capable and (hence) not RSVP capable. Assuming that PATH message 122 reaches receiver 118, receiver 118 originates a RESV message 126 that traverses RSVP capable routers 114, 108 and Ethernet switch 110 en route to sender 104. Routers 114, 108 each have IP and media access control (MAC) addresses, and are arranged to reserve resources in response to RESV message 126.
With reference to FIG. 2A, one method of attempting to establish path states prior to reserving resources in network 100 of FIG. 1 by sending a PATH message will be described. A process 200 of initiating the reservation of resources in network 100 of FIG. 1 using a PATH message begins at step 202 in which a sender sends a PATH message towards a receiver. The PATH message specifies an IP address associated with the sender, as for example an IP address of IP_0, and an IP address associated with the receiver, as for example an IP address of IP_3. The PATH message also specifies an IP address indicating the RSVP hop, as for example an IP address of IP_0 since the sender is the first RSVP hop. In step 204, a first router receives the PATH message and processes the PATH message as an RSVP message. Typically, when the first router identifies a Router Alert option in the IP header and identifies IP protocol number 46 in the PATH message, the first router initiates RSVP processing. RSVP processing of the PATH message includes updating the IP address of the RSVP hop, which in this case is set by the first router to IP_1. RSVP processing may include using a routing table to determine a layer 3 next hop and, hence, an outbound interface for the PATH message. As shown in FIG. 1, the next layer 3 hop towards the receiver is a second router with a MAC address of MAC_2. Hence, the first router sets a specified source MAC address in the Ethernet Header of the frame carrying the PATH message to its own MAC address, i.e., MAC_1, and sets a specified destination MAC address in the Ethernet header of the frame carrying the PATH message to MAC_2.
As will be appreciated by those skilled in the art, errors may occur during RSVP processing. By way of example, an error may occur if the first router effectively has no route or path to the receiver. Hence, in step 206, it is determined if an error has arisen during RSVP processing. If it is determined that an error has arisen, a path error (PATH_ERR) message is returned to the sender in step 207, and the process of reserving resources is terminated.
Alternatively, if the determination in step 206 is that no error has occurred during RSVP processing, the process flow proceeds to step 208 in which the first router forwards the path message to the Ethernet switch in the path between the first router and the second router. The routing table of the first router is used to identify the interface towards the Ethernet switch as being in the path towards the second router. The Ethernet switch is not an IP capable device and, as a result, is not even aware that the Ethernet frame actually carries an RSVP message. Thus, the Ethernet switch performs no RSVP processing and forwards the PATH message using the specified MAC addresses inside the Ethernet Header. Conventional rules of bridging are generally used by the Ethernet switch to forward the Ethernet frame which carries the PATH message using the MAC addresses to the second router in step 210. As will be appreciated by those skilled in the art, the Ethernet switch does not update any addresses specified in the PATH message.
On receipt of the PATH message, the second router will notice that its IP Header contains the Router Alert option and has an IP protocol number of 46 and hence initiate RSVP processing. The second router processes the path message in step 212 and uses a routing table to determine a layer 3 next hop. The second router also updates the IP address on the RSVP hop and sets it to IP_2. A determination is made in step 214 as to whether an error has arisen during RSVP processing. If it is determined that an error has arisen, a PATH_ERR message is returned towards the sender in step 214. When the second router returns the PATH_ERR message, the PATH_ERR message is returned with a source MAC address of the second router and a destination MAC address of the first router. Once the error message is returned to the sender, the process of establishing path states is terminated.
Returning to step 214, if it is determined that no error has arisen during RSVP processing, the indication is that the PATH message may be forwarded by the second router further towards its receiver. As such, the second router forwards the PATH message in step 216 to the receiver using the routing table of the second router to identify the path to the receiver. After the PATH message is forwarded to the receiver, the process of establishing path state end to end is completed. Note that each RSVP hop now knows the previous RSVP hop from the sender to the receiver.
When a PATH message is successfully received at a receiver, the receiver can send a RESV message back towards the sender of the PATH message to reserve resources. To ensure that the RESV message is sent along the same path used by the PATH message, the RESV message is routed hop-to-hop using path state information, including a previous RSVP hop, that was effectively set up during the processing of the PATH message. FIG. 2B is a process flow diagram which illustrates steps associated with processing a RESV message in network 100 of FIG. 1. A process 230 of reserving resources using a RESV message begins at step 232 in which a receiver sends a RESV message towards a sender with destination and source IP addresses specified. That is, the RESV message is sent by the receiver with a source IP address of IP_3, as receiver 118 of FIG. 1 is the source of the RESV message, and a destination IP address of IP_2, as second router 114 of FIG. 1 is the previous RSVP hop on the path from the sender to the receiver.
After being sent towards the sender, the RESV message is received and processed as an RSVP message in step 234 by the second router. The second router, i.e., router 114 of FIG. 1, identifies the RESV message as being an RSVP message. Path state information set up by the path message will be used by the first router to identify the next hop to which to forward the RESV message. A determination is made in step 236 as to whether there is an error in RSVP processing. An error may arise, for example, if there is an admission control failure relative to the second router. If it is determined that an error has arisen during RSVP processing by the second router, the second router returns a RESV error (RESV_ERR) message to the receiver, i.e., the originator of the RESV message, in step 237, and the processing of a RESV message is completed. The RESV_ERR message is returned with a source IP address set as the IP address of the second router, namely IP address IP_2, and a destination IP address set as the IP address of the RSVP next hop, namely IP address IP_3.
Alternatively, if it is determined in step 236 that there has been no error in RSVP processing, the second router forwards the RESV message to the Ethernet switch that is in the path between the second router and the first router. The second router generates the RESV message with a source addresses set to an address of the second router, and with a destination address set to an address of the first router. Upon receiving the RESV message, the Ethernet switch forwards the RESV message to the first router using MAC addresses in step 240. As the Ethernet switch is not an RSVP capable device, the Ethernet switch uses layer 2 address information to determine how to forward the RESV message. The Ethernet switch does not update addresses in the RESV message.
Once the Ethernet switch forwards the RESV message to the first router, the first router processes the RESV message as an RSVP message in step 242. Path state information set up by the path message will be used by the first router to identify the next hop to which to forward the RESV message. It is determined in step 244 whether an error has occurred in the course of RSVP processing. If it is determined that an error has occurred, then the first router returns a RESV_ERR message to the receiver in step 245. The RESV_ERR message is sent by the first router to the receiver with a source IP address of the RESV_ERR message set as the IP address of the first router, i.e., IP address IP_1, and with the destination IP address of the RESV_ERR message set as the IP address of the next RSVP hop, i.e., IP address IP_2. After the RESV_ERR message is sent, the processing of a RESV message is completed.
Returning to step 244, if it is determined that RSVP processing by the first router has not resulted in an error, then the first router forwards the RESV message to the sender using its routing table to identify a suitable outbound interface in step 246. Once the RESV message is forwarded to the sender, the processing of a RESV message is successfully completed.
Ethernet switches are not capable of providing admission control capabilities. In other words, Ethernet does not provide native admission control functionality available relative to layer 2 devices or layer 2 networks. Hence, though a path may effectively be reserved, if that path passes through an Ethernet switch or an Ethernet network, traffic sent on the reserved path may encounter congestion due to insufficient capacity when the traffic reaches the Ethernet switch or the Ethernet network.
To provide some admission control capabilities for layer 2 devices, an RSVP subnet bandwidth manager (SBM) may be implemented on each layer 2 device and on each edge device, or device on the edges of a layer 2 device or a layer 2 network. SBM is an extension of the RSVP protocol that enables on-path admission control at Ethernet hops located between IP hops, and is specified in RFC2814, which is incorporated herein by reference. Referring again to FIG. 1, Ethernet switch 110 may be an Ethernet hop that includes a SBM and a MAC layer agent, and routers 106, 114 may be IP hops that include SBM clients.
To implement SBM, an Ethernet hop inserts itself as an RSVP hop in the signaling path. This generally requires that the Ethernet hop implements an IP host functionality which includes having IP reachability into the layer 2 cloud and being allocated an IP address in this layer 2 cloud. Moreover, where multiple virtual local area networks (VLANs) are used in a layer 2 domain, the use of SBM to achieve admission control in substantially all the VLANs would generally require that the Ethernet hop implements an IP host functionality in each VLAN, and utilizes one separate IP address in each VLAN. Implementing such IP host functionality typically results in a more complicated implementation relative to an Ethernet hop, requires significant administration, and impacts scalability. Thus, providing admission control over an Ethernet hop via SBM may be inefficient.
Therefore, what is needed is a system that allows RSVP to be extended such that layer 2 devices may provide on-path signaling control without supporting IP forwarding functionality. That is, what is desired is a method and an apparatus for efficiently providing admission control capabilities for layer 2 devices.